Kyle McMeekin谈软件测试所面临的现实挑战(注释版)

（于航翻译，朱少民注释，见蓝色文字）

在最近举行的Agile2016会议上，InfoQ与Kyle McMeekin谈到了在敏捷开发中软件测试所面临的现实挑战。推动更多的自动化测试，以及与人工脚本测试相比，探索性测试有什么不同和为什么更有效。

infoQ：Kyle，请跟我们介绍一下你和QASymphony这家公司。

Kyle：QASymphony是一家软件公司，旨在帮助一些团队构建高质量的软件产品。我们正在帮助那些准备采用敏捷方法或正在向敏捷转型的团队、组织和公司。我们会提供一个软件来协助QA部门实现他们的敏捷计划。在QASymphony内部，我是一名高级产品工程师；我实际上负责掌管公司拥有的不同产品间的供给需求，提供产品展示，并与一些团队和组织合作，调整他们的业务流程与计划，使他们的工作流程能够与我们的工具相适应。

InfoQ：你在市场上看到的一些现实挑战都有什么？

Kyle：我认为向敏捷转型这种想法只是一个笼统的概念。因此我经常看到很多团队正在行动，并且他们声称自己已经变得敏捷，但这是什么意思？我每个月大概会和数百个客户聊天，经常会听到他们对于“敏捷”的不同定义（注：这的确是一个问题，大家对“敏捷”一词有不同的理解）。因此，我看到的一些挑战是需要为团队提供有一种能力和工具，来帮助他们的敏捷计划取得成功。通常，当我们与一些组织合作时，他们的开发团队变得越来越敏捷。他们会采用一些敏捷软件开发的ALM（生命周期管理软件），如JIRA，Rally，VersionOne，但QA测试人员却像被困在了孤岛上一样无助，充满了疑问，“我们到底应该怎样做才能变得更加敏捷？”。

通常，会有一个巨大的推动力迫使你的测试过程变得自动化。这些团队不想让他们的人工测试方法成为影响测试效率的瓶颈（注：手工测试和自动化测试可以相辅相成，下面讨论比较多的“探索式测试”就主要是手工方式），他们正在寻找可以进行自动化测试的方法。团队都主动地希望能够将测试流程变得更加自动化（注：测试流程不是自动化的主要标的，而是测试设计和执行、结果分析等自动化的主要标的）。除此之外，在大部分时间里我所听到的另一件事是关于“基于探索性的测试”。基于探索性的测试实际上是没有预先定义好的步骤来给你的测试人员和质量管理人员执行的（注：注：说明Kyle McMeekin／译者也没有真正掌握“探索式测试（Exploratory Testing，ET）”，它是一种方式，更强调是设计、执行和学习是同时发生的，思维更连贯，持续优化测试，使测试更具效率和价值，“探索性”并不是核心，也不是base。ET没有详细的测试用例，但依旧需要测试计划、设计，需要良好的测试思路，这里用“步骤”一词，容易引起误解）。因此，从一个基于瀑布模型的架构来看，你可能会通过手动的方式来运行测试脚本，并且你会声称，“我们正要完成第一个测试步骤，并且期望看到这样的结果”。而实际上你只是执行了运行测试脚本这个动作而已。

对于探索性测试（注：这次强调，不宜称“探索性测试”，而应称“探索式测试”），你不需要测试一个完整固定的用户流程，而是要像用户与产品交互那样，在测试的过程中随机应变，一边测试、一边计划，他们使用在测试中收集到的信息，影响自己进行测试的实际方式（注：这一段有比较多的错误，如果实施完全的ET，是可行的，而且需要测试完整的业务流程，需要很好的计划和设计，需要很好的分解测试目标和测试任务（如session）。虽然针对不同的测试结果的分析，可以调整测试的思路和测试的分配，这实际上就是一个持续的优化测试的过程）。你要用你自己对产品的理解来对应用进行测试。而不是漫无目的的在屏幕上随意点击。在进行探索性测试前，你需要根据用户类型来制定测试的目标。这里给出一个例子，“我作为一个管理员，想要去测试一个端对端的用例。因此，我们要去Amazon上检查想要选购的商品条目，并且把它添加到我的购物车里，输入我的付款信息等”。实际上，这整个用例测试流程对你来说并不是固定不变的。有很多不同的方案可以对这个用例进行测试。

所以，我认为从测试角度来看，测试人员在一个冲刺阶段（注：Sprint，最好翻译成“一个迭代”）内的测试能够覆盖整个应用功能的多少，是可以通过这种“基于探索性测试”的改进帮助他们加快测试进度的（注：ET只能是辅助的测试方式吗？读者可以思考 ）。他们不会被曾经使用的手动测试所限制。基于探索性的测试已经被证明能够发现更多的漏洞，这样便可以将这些漏洞在测试阶段就进行修复，而不是等到上线之后才发现。

InfoQ：如果探索性测试不是漫无目的的在屏幕上随意点击，那又是什么呢？你如何设置探索性测试的测试流程？

在进行基于探索性的测试之前，你通常会与团队讨论并且制定一个测试计划，指定一个测试目标。比如：我想要测试什么？我该担任什么角色？有什么类型的前提条件需要设置吗？讨论结束后，你会有一个简短的总结。你认为讨论在什么程度时可以结束？你在测试时会采用的一个与你同事所不一样的测试方法是什么？

我喜欢的一种方式是考虑并计划测试的方向（注：翻译的中文语句不同，英文是：So a way that I like to think about it is in terms of directions，正确的翻译是：我喜欢的一种思考方式就是从不同的方面进行ET测试（发散性思维））。我的意思是，如果你熟悉Waze或Google地图，你可能会在你的起始位置A点插入一个标记，接下来你可能想要到达B点的位置，但这些应用会提供不同的线路。我们可以选择第一条线路来避开那些正在施工的区域。或者选择第二条线路，虽然这条线路会比第一条线路长五公里，但是却可以欣赏到独特的风景。

因此，有不同的路线可以让你到达最终的目的地，这是我认为的使用基于探索性的测试的最简单的方式。在你从A点到B点的那段路上并不总是会有铁路轨道，但是在行进的过程中你却不会偏离这条线路。所以有很多不同的方法来测试一个用户是如何测试一个应用程序的。并不会总是采用这种规定好的直截了当的方法。（注：这属于应用场景的设想，测试人员是需要扮演不同的用户角色，从用户的角度去思考：他／她会如何使用这款软件？也就是说，测试人员需要良好的情景思维（形象思维）能力、发散思维（创新思维的一种）能力等，或借助思维导图、头脑风暴等工具／活动来帮助自己挖掘用户的应用场景 ）

我认为去发现这些细节是非常重要的，制定一个着手去做的计划，计划里记录你想要在开会时处理的事情。最终，这将使测试人员时刻保持他们的紧迫感（注：这段翻译有明显错误，原文是“Have a plan of attack in which you’re hoping to tackle during a session. And ultimately, that’s going to keep testers on their toes” ，这是的session 是一个集中执行ET的测试时间段，可以看作测试人员和系统的一次对话——不断质疑系统，有人将session翻译为“测程”，但我觉得还是翻译为“一次系统会话”比较好），attack 可以理解为“break software”的手段，keep someone on their toes是一种俗语表达方式，即“引起他们的警觉”。这段应该翻译为：需要制定一个测试计划，帮助测试会话中抓住测试要点，最终使测试人员能够对这些测试要点保持警觉  ）。这将允许他们使用自己的思考来创建不同的测试用例，而非他们现在正在做的事情————“定义基于指定脚本的测试（注：即ST，Scripted Testing），比如一个手动测试的用例”。

InfoQ：你曾声称探索性测试已经被证明可以找到更多的漏洞。你能给我们介绍下相关的背景吗？

我们的公司，QASymphony，曾经举办过一个关于“探索性测试”的网络研讨会。我们总结了一些幻灯片资料，并且我们曾经也与客户做过一些案例研究，在研究过程中允许他们使用我们公司开发的一个基于“探索性测试”的测试工具。从整体满意度、测试工作的满意度、价值的增加程度上来说，他们完全可以走出去，在跟自己人或者他人合作的时候展示他们曾经做过的这些成果。在这项研究背后涉及到的细节可以在找到（注：看了研究成果，ET比ST 缺陷发现能力提高了10%，研究也许有问题，应该远远超过10%）。这个调查是非常有影响力的，在这个领域中有很多不同的领军人物（注：主要有Cem Kaner, James Bach等）。是这个领域里的一位重要的领军人物，他提及到了很多关于探索性测试可以带来的附加价值。

InfoQ：非常感谢您抽出时间与我们交流。

不用客气。

关于受访者：

Kyle McMeekin是QASymphony的高级产品专家，专注于提供客户演示产品和相关技术的支持。他之前曾在Cognizant技术解决方案公司担任测试人员，并在公司扩张后从华盛顿特区附近搬到了亚特兰大。他是一个狂热的技术爱好者，同时他也是密歇根大学狼獾队的铁杆粉丝。

查看英文原文：